Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

nut13 specify keyset ID integer size: 32 bits #189

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

nut13 specify keyset ID integer size: 32 bits #189

wants to merge 1 commit into from

Conversation

vnprc
Copy link

@vnprc vnprc commented Nov 12, 2024 •
edited
Loading

Is the intention of this integer representation of keyset ID to fit it into 32 bits? I ran into this implementation in cdk that produces a u64 output which seems wrong to me.

https://github.com/cashubtc/cdk/blob/main/crates/cdk/src/nuts/nut02.rs#L117

impl TryFrom<Id> for u64 {
    type Error = Error;
    fn try_from(value: Id) -> Result<Self, Self::Error> {
        let hex_bytes: [u8; 8] = value.to_bytes().try_into().map_err(|_| Error::Length)?;

        let int = u64::from_be_bytes(hex_bytes);

        Ok(int % (2_u64.pow(31) - 1))
    }
}

I am opening this PR to get some clarity.

@vnprc vnprc mentioned this pull request Nov 12, 2024
Closed
lollerfirst
lollerfirst approved these changes Nov 12, 2024
View reviewed changes
13.md
@@ -42,7 +42,7 @@ The wallet starts with `counter_k := 0` upon encountering a new keyset and incre

#### Keyset ID

The integer representation `keyset_id_int` of a keyset is calculated from its [hexadecimal ID][02] which has a length of 8 bytes or 16 hex characters. First, we convert the hex string to a big-endian sequence of bytes. This value is then modulo reduced by `2^31 - 1` to arrive at an integer that is a unique identifier `keyset_id_int`.
The 32 bit integer representation `keyset_id_int` of a keyset is calculated from its [hexadecimal ID][02] which has a length of 8 bytes or 16 hex characters. First, we convert the hex string to a big-endian sequence of bytes. This value is then modulo reduced by `2^31 - 1` to arrive at an integer that is a unique identifier `keyset_id_int`.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am noticing something else here that is not per-se an issue but it's awkward: why reduce by 2^31-1 instead of 2^31? But I think I know why:

q % 2^31 == q & (2^31-1). Normally when reducing modulo a power of 2 you can skip division and just use a mask to get the desired bits. Whoever wrote this first must have confused this or made a typo.
Now we can't change this back without breaking the protocol but I thought it was funny.

@prusnak
Copy link
Collaborator

prusnak commented Nov 12, 2024 •
edited
Loading

NACK. This is implementation specific (some languages do not have 32-bit int) and the intention is obvious from the provided examples.

@vnprc
Copy link
Author

vnprc commented Nov 12, 2024

I disagree that it's obvious. I opened this PR because I found the language confusing. It seems to assume the term 'integer' means a 32 bit number. The python example is clear to me but the javascript example uses BigInt() twice to arrive at a number that fits into a regular int.

I think the language does a good job explaining that the input is 8 bytes or 16 hex chars but does not explicitly say the size of the output. The size of the container of the function output is an implementation specific detail but it would be helpful to explain that the output of this function fits into 32 bits or 4 bytes or 8 hex chars.

@prusnak would this language be better?

The integer representation keyset_id_int of a keyset is calculated from its hexadecimal ID which has a length of 8 bytes or 16 hex characters. First, we convert the hex string to a big-endian sequence of bytes. This value is then modulo reduced by 2^31 - 1 to arrive at a unique identifier keyset_id_int that can be stored in 4 bytes or 8 hex chars.

@clarkmoody
Copy link

I like the idea of specifying that the keyset ID should be able to fit into a 32-bit integer. Maybe the spec should just constraint the range of valid values?

@prusnak
Copy link
Collaborator

prusnak commented Nov 12, 2024

... that can be stored in 4 bytes or 8 hex chars.

The value is not stored anywhere - it is just used as an input to BIP32 child key derivation (CKD) function. Therefore I find it irrelevant whether the value is stored in 32-bit int, 64-bit int, 4 bytes etc. Because all that matters is what is the data type that CKD is expecting (and yeah, in statically typed languages it is usually uint32, but can be literally any int type).

@vnprc
Copy link
Author

vnprc commented Nov 12, 2024

Ok, sure. My goal in suggesting this change is to make it more clear to devs implementing this spec.

@vnprc vnprc mentioned this pull request Nov 13, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lollerfirst lollerfirst lollerfirst approved these changes

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@vnprc @prusnak @clarkmoody @lollerfirst